Use ReadOnlyMemory<byte> for binary data to eliminate UTF-16 transcoding by Copilot · Pull Request #1070 · modelcontextprotocol/csharp-sdk

Copilot · 2025-12-05T22:42:03Z

Plan: Fix Binary Data Representation in Protocol Types

Based on the issue analysis, I need to change how binary data is represented in the protocol types to avoid unnecessary UTF-16 transcoding.

Changes Completed:

Summary:

Successfully converted binary data properties from string to ReadOnlyMemory<byte> with complete elimination of UTF-16 transcoding:

Wire format: Base64-encoded UTF-8 bytes stored directly from JSON
Decoding: Direct UTF-8 → binary via Base64.DecodeFromUtf8 (no string intermediate on .NET)
Caching: Lazy decode with result caching
Initialization: Factory methods (FromData, FromBytes) for efficient creation from binary data
Consistency: DecodedData naming across all binary types, FromBytes naming for factory methods
Code reuse: Base64Helpers class deduplicates encode/decode logic
Helper methods: GetBase64Utf8Bytes deduplicates DataContent extraction

Original prompt

This section details on the original issue you should resolve

<issue_title>Content types that represent binary data are exposing UTF16 encoded strings</issue_title>
<issue_description>

csharp-sdk/src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

Lines 25 to 29 in 4a84412

/// <summary>

/// Gets or sets the base64-encoded string representing the binary data of the item.

/// </summary>

[JsonPropertyName("blob")]

public required string Blob { get; set; }

csharp-sdk/src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

Lines 377 to 381 in 4a84412

/// <summary>

/// Gets or sets the base64-encoded image data.

/// </summary>

[JsonPropertyName("data")]

public required string Data { get; set; }

csharp-sdk/src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

Lines 399 to 403 in 4a84412

/// <summary>

/// Gets or sets the base64-encoded audio data.

/// </summary>

[JsonPropertyName("data")]

public required string Data { get; set; }

Potentially more -- https://github.com/search?q=repo%3Amodelcontextprotocol%2Fcsharp-sdk%20%22base64-encoded%22&type=code

Doing this means that the UTF8 data that comes across the wire is transcoded to UTF16 just to be then base64 decoded to bytes when anyone uses it. The intermediate step to UTF16 (.NET string) is unnecessary, wastes cycles, creates garbage, and makes the API harder to use.

Instead these types should keep the data in UTF8 and then have lazy getters that will do the base64-decoding. We can tell folks to use those decoded getter properties.

https://github.com/dotnet/extensions/blob/main/src/Libraries/Microsoft.Extensions.AI.Abstractions/Contents/DataContent.cs follows a similar pattern, though it uses the Uri as it's serialized representation. It seems these MCP types should use the UTF8 encoded data as their serialized representation.

The OpenAI SDK exposes a BinaryData as its representation to deal with this problem https://github.com/openai/openai-dotnet/blob/636075222205d626a770acb1af1e5cc060abd517/src/Custom/Images/GeneratedImage.cs#L23 however that's slightly less usable since it forces the caller to decode.

The proposal here would be to have these be instead:
/// <summary> 
/// Gets or sets the base64-encoded UTF-8 byes representing the binary data of the item.
/// </summary> 
/// <remarks>
/// This is a zero-copy representation of the wire payload of this item.  Setting this value will invalidate any cached value of <see cref="Data" />.
/// </remarks>
[JsonPropertyName("blob")] 
public required ReadOnlyMemory<byte> Blob { get; set; } 

/// <summary> 
/// Gets the decoded data represented by <see cref="Blob" />.
/// </summary>
/// <remarks>
/// Accessing this member will decode the value in <see cref="Blob" /> and cache the result.
/// </remarks>
[JsonIgnore]
public byte[] Data { get; }
</issue_description>

<agent_instructions>Please find any protocol types that expose binary data as string (typically base64 encoded) and follow the cited recommendations for how to expose them differently.</agent_instructions>

Comments on the Issue (you are @copilot in this section)
@stephentoub > The proposal here would be to have these be instead:
Should Data also be a ReadOnlyMemory<byte>?

Is Data going to cache the decoded data lazily, or is it going to produce a new array on each access? If the latter, it shouldn't be a property.

what do you think about the name Blob

I'm torn. On the one hand, I agree with you. On the other hand, it's nice to keep it the same or super close to the spec. Offline you'd proposed something like Base64Blob; is that still your first choice?</comment_new>

Fixes Content types that represent binary data are exposing UTF16 encoded strings #1064

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

src/ModelContextProtocol.Core/Server/AIFunctionMcpServerResource.cs

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

src/ModelContextProtocol.Core/Server/AIFunctionMcpServerResource.cs

stephentoub · 2025-12-08T04:37:06Z

@ericstj, I'm not sure this will actually end up saving much end-to-end. It'd help if some of the data wasn't actually looked at, but if it ends up being looked at, it seems it'll actually make the end-to-end worse.

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

ericstj · 2025-12-08T18:22:54Z

I see this PR is still going though a string when decoding - I thought we had API that would go straight from ROS (base64 UTF8) to byte[] without an intermediate string.

stephentoub · 2025-12-08T18:29:42Z

I thought we had API that would go straight from ROS (base64 UTF8) to byte[] without an intermediate string.

We have operation status APIs that write into an existing destinatiom buffer, but no one-shot that creates the array. We do for Base64Url but we didn't square the circle for Base64.

ericstj · 2025-12-08T19:46:06Z

Can't we do Base64.GetMaxDecodedFromUtf8Length to get the size, create a byte array, then Base64.DecodeFromUtf8, followed by slice to final actual size?

stephentoub · 2025-12-08T19:59:39Z

Base64.DecodeFromUtf8

That's the operation status API I was referring to.

Can't we do Base64.GetMaxDecodedFromUtf8Length to get the size, create a byte array, then Base64.DecodeFromUtf8, followed by slice to final actual size?

I thought you'd stated you wanted the decoded data property to be a byte[]. If it is, slicing would entail allocating a whole new array unless the max happened to equal actual, which would happen only ~33% of the time.

If the destination property is a ReadOnlyMemory<byte>, then yes, it can be done that way.

ericstj · 2025-12-09T01:25:02Z

If the destination property is a ReadOnlyMemory<byte>, then yes, it can be done that way.

This is exactly what I was thinking of when mentioning:

If using ROM avoids a copy it's acceptable.

And the current implementation is already exposing as public ReadOnlyMemory<byte> DecodedData so I think we've already committed to this. Let's go ahead and remove those string intermediates. @copilot

Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

Copilot · 2025-12-09T01:37:48Z

If the destination property is a ReadOnlyMemory<byte>, then yes, it can be done that way.

This is exactly what I was thinking of when mentioning:
...

Implemented using Base64.DecodeFromUtf8 to decode directly from UTF-8 bytes without string intermediate in commit 39213fb. The implementation:

Uses Base64.GetMaxDecodedFromUtf8Length to allocate the buffer
Calls Base64.DecodeFromUtf8 to decode directly
Slices to actual size using ReadOnlyMemory when needed (only allocates new array ~33% of time when actual != max)
Falls back to optimized string-based approach for .NET Standard 2.0

stephentoub · 2026-01-21T16:51:24Z

@ericstj, is this something you're still interested in pushing forward?

ericstj · 2026-01-21T17:15:00Z

Yes, thanks for the reminder. Let me refresh my memory on it and have a look this week.

ericstj · 2026-01-27T18:32:39Z

Fixing up the merge conflict.

…om data. These factories go straight from data -> base64 utf-8 encoded data without excess garbage.

…-sdk into copilot/fix-binary-data-encoding

ericstj · 2026-01-30T16:46:14Z

Test failure is #1222

ericstj · 2026-02-05T00:28:00Z

@stephentoub when you have a chance would appreciate your pass on this once more, since I'm the last committer.

stephentoub · 2026-02-05T03:10:25Z

samples/EverythingServer/Resources/SimpleResourceType.cs

            new BlobResourceContents
            {
-                Blob = resource.Description!,
+                Blob = System.Text.Encoding.UTF8.GetBytes(resource.Description!),


@copilot, we prefer to use simple rather than fully-qualified names. Can these "System.Text"s be moved instead to usings at the beginning?

stephentoub · 2026-02-05T03:15:28Z

src/ModelContextProtocol.Core/AIContentExtensions.cs

+            // gets UTF-8 bytes from UTF-16 chars without intermediate string allocations
+            fixed (char* pChars = utf16)
+            {
+                var byteCount = System.Text.Encoding.UTF8.GetByteCount(pChars, utf16.Length);
+                var bytes = new byte[byteCount];
+
+                fixed (byte* pBytes = bytes)
+                {
+                    System.Text.Encoding.UTF8.GetBytes(pChars, utf16.Length, pBytes, byteCount);
+                }
+                return bytes;
+            }


@copilot, this shouldn't require unsafe code on .NET Core... there are overloads that work with spans, so this can be e.g.

byte[] bytes = new byte[Encoding.UTF8.GetByteCount(utf16)] Encoding.UTF8.GetBytes(utf16, bytes); return bytes;

For the netstandard2.0 build, you can add polyfills for these methods in https://github.com/modelcontextprotocol/csharp-sdk/tree/main/src/Common/Polyfills/System

I had used the unsafe code to avoid the ifdef, I agree a polyfill approach should work. Thanks for suggestion.

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

stephentoub · 2026-02-05T03:18:09Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

+                    throw new FormatException("Invalid base64 data");
+                }
+            }
+            return _decodedData.Value;


@copilot

Suggested change

return _decodedData.Value;

return _decodedData.Value;

stephentoub · 2026-02-05T03:20:26Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

+    /// </para>
+    /// </remarks>
+    [JsonIgnore]
+    public ReadOnlyMemory<byte> Data


@ericstj why do you call this Data here but DecodedData elsewhere like on ContentBlock?

We can change it.

The change was made here 4287694#diff-9da29ad32a17c90e9b28c79ad3ab9c4b370a757e26657c736020ea47314a60ba

I had assumed we would have liked to use Data everywhere, since that's the better name and more-likely the "useful" property for the caller. The ContentBlock types had already used Data to mean the encoded data, so we didn't change that.

I agree that consistency is better here - lets use DecodedData here. What are your thoughts on Blob vs Data for the encoded data? Should we keep those different between content and resource types (since it's preexisting discrepancy) or try to make the consistent?

Should we keep those different between content and resource types (since it's preexisting discrepancy) or try to make the consistent?

I think there's value in keeping the names of these C# properties aligned with their spec / JSON schema counterparts. I don't know why they differ in the MCP spec, but alas.

Ok, we'll keep them different, but rename Data to DecodedData here.

ericstj · 2026-02-06T16:10:36Z

@copilot please address feedback

…sed encoding, remove System.Text qualifiers Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

Copilot · 2026-02-06T16:22:16Z

@copilot please address feedback

Addressed all feedback in commit 0a3015f:

Renamed Data to DecodedData in BlobResourceContents for consistency
Removed unsafe code from AIContentExtensions, using span-based Encoding methods
Created EncodingExtensions polyfill for netstandard2.0 support
Moved System.Text to using statements in sample files
Added Debug.Assert for bytesWritten validation
Return _decodedData.Value directly as suggested
All binary data tests passing

stephentoub · 2026-02-06T16:35:59Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

-/// the Model Context Protocol. The binary data is represented as a base64-encoded string
-/// in the <see cref="Blob"/> property.
+/// the Model Context Protocol. The binary data is represented as base64-encoded UTF-8 bytes
+/// in the <see cref="Blob"/> property, providing a zero-copy representation of the wire payload.


It's still copied. It just doesn't have its encoding changed.

True, we don't control the buffering during serialization or to network payload. This type itself won't copy when initialized with pre-encoded bytes. Hypothetically something using the type could slot these bytes into a a sequence of ROM for a zero-copy solution.

I agree that this is not really a useful doc change though. This is just a case of copilot making the rookie mistake of commenting on the diff instead of the result.

We should remove all mention of zero-copy from this change.

stephentoub · 2026-02-06T16:37:27Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

+        byte[] buffer = new byte[maxLength];
+        if (Base64.EncodeToUtf8(data.Span, buffer, out _, out int bytesWritten) == OperationStatus.Done)
+        {
+            Debug.Assert(bytesWritten == buffer.Length, "Base64 encoding should always produce exact length for non-padded input");


Suggested change

Debug.Assert(bytesWritten == buffer.Length, "Base64 encoding should always produce exact length for non-padded input");

Debug.Assert(bytesWritten == buffer.Length, "Base64 encoding should always produce the same length as the max length");

stephentoub · 2026-02-06T16:38:33Z

src/ModelContextProtocol.Core/Protocol/BlobResourceContents.cs

+    /// Gets or sets the base64-encoded UTF-8 bytes representing the binary data of the item.
    /// </summary>
+    /// <remarks>
+    /// This is a zero-copy representation of the wire payload of this item. Setting this value will invalidate any cached value of <see cref="DecodedData"/>.


The "zero-copy representation of the wire payload" part of this is confusing.

stephentoub · 2026-02-06T16:41:48Z

src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

+                    throw new FormatException("Invalid base64 data");
+                }
+            }
+            return _decodedData.Value;


Suggested change

return _decodedData.Value;

return _decodedData.Value;

stephentoub · 2026-02-06T16:48:54Z

src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

+    /// <param name="mimeType">The MIME type of the audio.</param>
+    /// <returns>A new <see cref="AudioContentBlock"/> instance.</returns>
+    /// <exception cref="InvalidOperationException"></exception>
+    public static AudioContentBlock FromAudio(ReadOnlyMemory<byte> audioData, string mimeType)


I'm not sure about the FromImage and FromAudio naming. These are already _Image_ContentBlock and _Audio_ContentBlock. Is the word in the name duplicative? Should these be FromBytes or FromRawData or something like that? If we can't come up with anything better, we can go with the current names, it's just a little strange to me, both with the duplication and with this saying it's from audio/images but the arguments are arbitrary bytes/mimeType, and there's no validation that it's actually audio/image.

I'm good with FromBytes. I was thinking FromData didn't work because of existing Data properties. Let's rename to FromBytes and mention in comments that it represents decoded bytes and using these methods will retain a reference of the provided bytes as the DecodedData and will encode them to Data.

stephentoub · 2026-02-06T16:49:37Z

src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

+        // Encode directly to UTF-8 base64 bytes without string intermediate
+        int maxLength = Base64.GetMaxEncodedToUtf8Length(audioData.Length);
+        byte[] buffer = new byte[maxLength];
+        if (Base64.EncodeToUtf8(audioData.Span, buffer, out _, out int bytesWritten) == OperationStatus.Done)
+        {
+            data = buffer.AsMemory(0, bytesWritten);
+        }
+        else
+        {
+            throw new InvalidOperationException("Failed to encode binary data to base64");
+        }


Is this exact code duplicated? Can we dedup into a helper function? Same for the other direction.

stephentoub · 2026-02-06T16:49:54Z

src/ModelContextProtocol.Core/Protocol/ContentBlock.cs

+                    throw new FormatException("Invalid base64 data");
+                }
+            }
+            return _decodedData.Value;


Suggested change

return _decodedData.Value;

return _decodedData.Value;

stephentoub · 2026-02-06T16:50:54Z

src/ModelContextProtocol.Core/Server/AIFunctionMcpServerResource.cs

+                    Blob = MemoryMarshal.TryGetArray(dc.Base64Data, out ArraySegment<char> segment)
+                        ? Encoding.UTF8.GetBytes(segment.Array!, segment.Offset, segment.Count) 
+                        : Encoding.UTF8.GetBytes(dc.Base64Data.ToString()) 


This and the below can also be deduped into a helper function for getting an array from a DataContent

ericstj · 2026-02-07T00:53:04Z

@copilot please address feedback, and be sure to consider variants of each suggestion.

…dio to FromBytes, add Base64 helpers, fix Encoding references Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

Copilot · 2026-02-07T01:06:45Z

@copilot please address feedback, and be sure to consider variants of each suggestion.

Addressed all feedback in commit e4f2816:

Removed all "zero-copy" claims from documentation
Updated Debug.Assert message as suggested
Renamed FromImage/FromAudio to FromBytes with updated documentation
Created Base64Helpers class to deduplicate encode/decode logic (used by BlobResourceContents, ImageContentBlock, AudioContentBlock)
Created GetBase64Utf8Bytes helper to deduplicate DataContent Base64Data extraction
Fixed System.Text.Encoding references in Base64Helpers for netstandard2.0
Updated all tests to use FromBytes
All tests passing

Initial plan

7dca602

Copilot AI assigned Copilot and stephentoub Dec 5, 2025

Copilot started work on behalf of stephentoub December 5, 2025 22:42 View session

Copilot AI and others added 3 commits December 5, 2025 23:00

Update protocol types to use ReadOnlyMemory<byte> for binary data

4287694

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Fix test files to work with new binary data representation

8e6fcf0

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Add cache invalidation when Blob/Data properties are set

e405dfc

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix binary data types exposing UTF16 encoded strings~~ Use ReadOnlyMemory<byte> for binary data to eliminate UTF-16 transcoding Dec 5, 2025

Copilot AI requested a review from stephentoub December 5, 2025 23:28

Copilot finished work on behalf of stephentoub December 5, 2025 23:28

stephentoub requested a review from ericstj December 8, 2025 03:42

stephentoub reviewed Dec 8, 2025

View reviewed changes

Copilot started work on behalf of stephentoub December 8, 2025 04:21 View session

Apply performance optimizations using MemoryMarshal.TryGetArray

ebe3eef

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI requested a review from stephentoub December 8, 2025 04:31

Copilot finished work on behalf of stephentoub December 8, 2025 04:31

stephentoub reviewed Dec 8, 2025

View reviewed changes

src/ModelContextProtocol.Core/Server/AIFunctionMcpServerResource.cs Outdated Show resolved Hide resolved

Copilot started work on behalf of stephentoub December 8, 2025 04:36 View session

Use GetBytes overload with offset and count parameters

1d76c11

Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com>

Copilot AI requested a review from stephentoub December 8, 2025 04:43

Copilot finished work on behalf of stephentoub December 8, 2025 04:43

Copilot started work on behalf of ericstj December 9, 2025 01:25 View session

Use Base64.DecodeFromUtf8 to avoid string intermediate during decoding

39213fb

Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

scutuatua-crypto approved these changes Jan 10, 2026

View reviewed changes

Merge branch 'main' into copilot/fix-binary-data-encoding

a4ba4a9

ericstj added 7 commits January 27, 2026 11:17

Fix merge conflict with DebuggerDisplay

b4e4eaf

Cleanup refactoring

61f0dfa

Remove string from DataContent conversion

5de847c

Add factory methods to data backed types to efficiently initialize fr…

dc01608

…om data. These factories go straight from data -> base64 utf-8 encoded data without excess garbage.

Update some tests to use factory methods

2fc35d9

Fix test assertions in McpServerToolTests

14fedca

Merge branch 'main' of https://github.com/modelcontextprotocol/csharp…

b3eacff

…-sdk into copilot/fix-binary-data-encoding

ericstj marked this pull request as ready for review February 2, 2026 18:31

ericstj previously approved these changes Feb 5, 2026

View reviewed changes

stephentoub reviewed Feb 5, 2026

View reviewed changes

Copilot started work on behalf of ericstj February 6, 2026 16:11 View session

Address code review feedback: rename Data to DecodedData, use span-ba…

0a3015f

…sed encoding, remove System.Text qualifiers Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

Copilot AI dismissed ericstj’s stale review via 0a3015f February 6, 2026 16:22

Copilot finished work on behalf of ericstj February 6, 2026 16:23

Copilot AI requested a review from ericstj February 6, 2026 16:23

stephentoub reviewed Feb 6, 2026

View reviewed changes

Copilot started work on behalf of ericstj February 7, 2026 00:53 View session

Address code review: remove zero-copy claims, rename FromImage/FromAu…

e4f2816

…dio to FromBytes, add Base64 helpers, fix Encoding references Co-authored-by: ericstj <8918108+ericstj@users.noreply.github.com>

Copilot finished work on behalf of ericstj February 7, 2026 01:07

	/// <summary>
	/// Gets or sets the base64-encoded string representing the binary data of the item.
	/// </summary>
	[JsonPropertyName("blob")]
	public required string Blob { get; set; }

	/// <summary>
	/// Gets or sets the base64-encoded image data.
	/// </summary>
	[JsonPropertyName("data")]
	public required string Data { get; set; }

	/// <summary>
	/// Gets or sets the base64-encoded audio data.
	/// </summary>
	[JsonPropertyName("data")]
	public required string Data { get; set; }

	Debug.Assert(bytesWritten == buffer.Length, "Base64 encoding should always produce exact length for non-padded input");
	Debug.Assert(bytesWritten == buffer.Length, "Base64 encoding should always produce the same length as the max length");

Conversation

Copilot AI commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Plan: Fix Binary Data Representation in Protocol Types

Changes Completed:

Summary:

Comments on the Issue (you are @copilot in this section)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

stephentoub commented Dec 8, 2025

Uh oh!

ericstj commented Dec 8, 2025

Uh oh!

stephentoub commented Dec 8, 2025

Uh oh!

ericstj commented Dec 8, 2025

Uh oh!

stephentoub commented Dec 8, 2025

Uh oh!

ericstj commented Dec 9, 2025

Uh oh!

Copilot AI commented Dec 9, 2025

Uh oh!

stephentoub commented Jan 21, 2026

Uh oh!

ericstj commented Jan 21, 2026

Uh oh!

ericstj commented Jan 27, 2026

Uh oh!

ericstj commented Jan 30, 2026

Uh oh!

ericstj commented Feb 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

stephentoub Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ericstj Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ericstj commented Feb 6, 2026

Uh oh!

Copilot AI commented Feb 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Copilot AI commented Dec 5, 2025 •

edited

Loading

stephentoub Feb 5, 2026 •

edited

Loading

ericstj Feb 5, 2026 •

edited

Loading